Unity v 2019.1.3f1
AC v1.72.4
2 weeks away from release and there's this huge game breaking bug I can't get to the bottom of!
I have a bunch of custom speech menus that I created using the script in this thread - https://www.adventurecreator.org/forum/discussion/8736/multiple-styles-of-conversation-boxes-menus-lock-menu-turn-off-menu
One of those boxes often shows up without any text. The issue is sometimes the text does show up, other times this bug happens - it seems to be random.
What it looks like -
" alt="" title="" />
What it's supposed to look like -
" alt="" title="" />
Speech menus -
" alt="" title="" />
" alt="" title="" />
" alt="" title="" />
Help appreciated, thanks!
It looks like you're new here. If you want to get involved, click one of these buttons!
Comments
This behaviour is similar to if I were to have unchecked "Is Visible" for the SubsLineLabel Menu Element. But it is in fact checked. Although, there are some points in the game where I've hidden this menu element through an ActionList. It is possible that if users quit the game at that point, the element remains hidden on launching and loading up the game?
The script in that thread is a custom Action that allows you to unlock a specific Speech menu, while locking others, when your speech is played.
How have you modified this Action, how/when are you using it, and are you mixing it in with regular Speech Actions?
On top of locking/unlocking your Menus through the custom Action, your Speech menu also limits itself by the speaking character. This will impact the menu's display regardless of the Action - it'll only ever display speech spoken by "stacks subs npc" and "book subs npc". Are either of these NPCs the ones speaking the example text in your screenshot?
Bear in mind that the custom Action in that thread doesn't revert the state of any Menus afterwards. If a Menu becomes locked because of it, it will remain so.
Could it be that the seemingly-random behaviour is more to do with the order in which such Actions are run, based on user choices, and so altering the state of which menus are available to display speech?
It may be that an alternative to the linked script can be found. What is the root issue you're trying to address with it?
The Is visible? checkbox only represents the element's default state - it doesn't represent its state at runtime.
Here's a test script that forces it's visibility on whenever speech plays: see if that has an effect.
Element visibility states are recorded in save games, so they will be restored upon loading a save - but not when purely starting the game.
Yes, I make sure they are the ones speaking those dialogues (The menu wouldn't appear at all if they weren't the speaker - it wouldn't be this bug)
So then this is a possibility (player quitting and it getting saved as invisible) But yes - the big issue is that this bug also occurs (randomly) on fresh playthroughs/ new game start.
So in my game's ActionList on start game, I've created an action that ensures the element is visible through Show Menu Element. Would this script do the same thing?
Also, do I add that script to an empty gameobject in every scene to make it work?
I haven't modified it, and I have disabled the original Speech menu. I wasn't aware it locks the others and unlocks the one it's using. But either way - it should unlock it in that case right?
And if it was only locked - the menu wouldn't appear at all. Here the menu does appear, but is missing text. Which means it's unlocked but the SubsLineLabel element is just hidden.
The custom Action / various speech menus may be a red herring, then. The real source is most likely the element being hidden.
The script un-hides the element as the Speech begins - i.e. just before the Menu turns on to display it. If you've hidden the element after starting the game, this'll re-show it.
At this stage, it's just a test to see if this is the real issue. Just place it anywhere in a single scene for now, and see if the issue still occurs in that scene.
Will do, thanks for all the quick help! The issue with this bug is that it's hard to reproduce, so it'll be tough to confirm if it has been fixed or not. Either way, I'll keep you updated, thanks!
@ChrisIceBox The tester that encountered this issue has now confirmed that it's fixed! Thank you so much for the code and for the quick help!